一句话总结
SRE入职前90天的核心任务不是学习多少新工具，而是用正确的方式验证自己已有的能力能否在新的基础设施上落地——大多数SRE的失败不是输在技术深度，而是输在以为“会用Terraform”就等于“能搞定生产环境”。这不是一份技术学习清单，而是一份判断清单：判断你面前的这家公司和你想象的是否真的是同一种SRE。
适合谁看
这篇文章写给三类人。第一类是即将入职SRE岗位的候选人，无论你是从传统运维转型还是从开发转岗，这篇文章帮你判断自己是否真的准备好了。第二类是正在经历SRE面试的候选人，文章里会拆解面试流程的每一轮考察重点和薪资构成，帮你把“准备面试”变成“准备判断”。第三类是SRE团队的管理者，你可以用这份清单作为新人90天review的框架，但它不是给你用的——是给你手下的SRE用的。
如果你正在面Google的SRE岗位，你需要的不是这篇文章，而是去搜Google SRE的官方面试指南。如果你面的公司规模小于50人，这篇文章的大部分内容对你没有意义——小公司的SRE本质上是全栈工程师，不是运维专家。
核心内容
监控告警体系：你真的理解公司的监控stack吗
大多数SRE在入职第一周会做一件极其浪费时间的事情：把公司用的监控工具全部装一遍、文档全部读一遍。以为“会用Prometheus+Grafana”就等于理解了公司的监控体系。这不是理解监控，这是在给自己砌墙。
真正的监控体系认知是从三个问题开始的。第一，公司的SLO是谁制定的，制定的依据是什么——不是告警阈值，是SLO。第二，过去六个月线上出过哪些事故，这些事故的告警是在哪个阶段被触发的，触发后为什么没有第一时间引起重视。第三，监控数据的所有权在谁手里，是SRE团队还是各业务团队自己维护。
我见过一个具体的例子。某硅谷中厂入职一个SRE，第一天就把Datadog的dashboard从头到尾翻了一遍，笔记做了二十页。一个月后上线第一个变更，凌晨三点被page醒，发现自己根本不知道这个服务的告警策略是谁写的、为什么这么写、为什么同样的告警隔壁组被page而自己这组没被page。后来他才知道，告警策略是上一任SRE离职前随手配置的，没有任何文档，而隔壁组是主动要求增加告警的。
这不是监控工具的问题，是监控治理的问题。入职90天内，你必须找到并理解这三个角色的分工：谁定义SLO，谁配置告警阈值，谁决定告警发到哪个channel。如果这三件事没有人能说清楚，这家公司的SRE成熟度远低于你简历上写的“熟练使用Prometheus”。
故障处理流程：你的Incident Response流程有多少是纸上谈兵
每个公司都有incident response流程文档，大多数文档的阅读体验和飞机上的安全须知一样——你不会真的去读，读了也不会真的照做。入职90天内，你必须验证这个文档在真实事故中被执行的程度。
具体做法是找到过去三个月的post-mortem（事故复盘报告）。不是让你去读结论，是让你去对比：文档里写的incident commander角色在实际事故中是谁在担任，文档里写的communication template在实际事故中有没有被使用，文档里说的“每小时更新一次状态”在实际事故中做到了吗。
一个insider场景是这样的：某公司SRE入职第二周遇到一次数据库故障，按照incident response文档，他应该先确认incident severity level，然后assign incident commander，然后启动communication channel。但他发现实际情况是：CTO直接拉了一个Slack channel把所有人都拉进去，incident commander被skip了，status page更新的是市场部的人而不是on-call SRE。这个SRE后来跟我说，他入职前以为这家公司有成熟的incident response流程，入职后发现文档是上一任SRE写的，写完就走了，没有人真的用过。
这不是让你去改变流程，是让你在90天内判断：这个公司的incident response是“文档驱动”还是“事件驱动”。如果是前者，你入职后的很大一部分工作会是维护一份没有人看的文档。如果是后者，你需要快速找到那个在真实事故中真正做决定的人——往往不是title上写着SRE Manager的人。
自动化运维：自动化是口号还是真实的生产力
SRE简历上几乎都会写“具备自动化能力”，面试时几乎都会被问到“你怎么做自动化”。但自动化有三个层次，大多数SRE只停留在第一个层次。
第一层是脚本自动化：用Python写个脚本自动跑某个检查，用Cron job定时执行。这叫自动化，但这不是SRE意义上的自动化。第二层是工具链自动化：把监控、告警、部署、回滚串在一起，一个trigger触发一串动作。这叫CI/CD，但这还不是SRE的核心自动化。第三层是基础设施即代码：整个环境的provision、configuration、scaling都是代码定义，任何人拉下代码都能重建生产环境。这才是SRE的自动化。
入职90天内，你不需要自己写出第三层的代码，但你需要判断公司目前在哪一层。具体方法是问一个简单的问题：如果现在需要重建整个staging环境，需要几个人，花多长时间。如果答案是“需要三周”或者“没有人知道完整步骤”，这家公司大概率还停留在第一层。如果答案是“一个人两天”，这家公司才有资格谈SRE。
还有一个更直接的判断方式：去看公司的change failure rate（变更失败率）。如果一个SRE团队连自己上个月的change failure rate都说不出来，这团队的自动化水平不需要问了。change failure rate是Google SRE book里提出的四个关键指标之一，如果一个公司不关注这个指标，说明这家公司对SRE的理解还停留在“运维换了个名字”的阶段。
容量规划：你知道系统的红线在哪里吗
容量规划是SRE最容易被高估也最容易被低估的能力。说它被高估，是因为很多SRE把容量规划理解成“看看监控数据然后调一下阈值”。说它被低估，是因为真正的容量规划需要理解业务逻辑、技术架构和成本控制三者的交集。
入职90天内，你必须找到这个问题的答案：如果流量突然增长10倍，哪些服务会先挂掉。这个问题不是让你去回答，是让你去观察——观察有没有人知道答案，观察这个答案是否被文档化，观察这个答案在过去一年里有没有被验证过。
一个具体的场景是某电商公司的SRE入职第三个月遇到了黑色星期五。事前他问tech lead有没有做容量规划，tech lead说“应该没问题，我们加了auto-scaling”。结果凌晨三点auto-scaling触发了，但数据库连接池打满了，整个网站挂了两个小时。事后复盘发现：没有人做过数据库的容量规划，auto-scaling只考虑了CPU，没有考虑数据库瓶颈。
这不是tech lead的错，这是SRE团队的失职。容量规划不是SRE一个人的事情，但SRE是那个必须推动这件事的人。入职90天内，如果你还没有找到系统的红线在哪里，还没有和业务团队对过“流量增长10倍”这个假设，你的capacity planning就是零。
安全合规：安全不是运维的选修课
很多SRE把安全当成“运维之外的另一件事”。这种认知在2024年的硅谷是致命的。越来越多的公司在招聘SRE时把“安全能力”从nice-to-have变成了must-have，而且不是那种泛泛的“安全意识”，是具体的安全实践能力。
入职90天内，你必须理解三个安全相关的概念在你们公司的具体实现。第一是RBAC（基于角色的访问控制）：谁可以访问生产环境，访问的权限级别是什么，权限变更的流程是什么。第二是secret management：密钥和密码怎么存储，怎么轮换，怎么在CI/CD中使用。第三是network security：生产环境和办公网络的关系，VPC怎么划分，防火墙规则是谁在维护。
一个常见的错误是SRE以为这些是security team的事情。没错，这些确实是security team的职责范围，但SRE是那个在生产环境中执行安全策略的人。如果security team说“生产环境应该用IAM role而不是access key”，但SRE团队为了省事还在用access key，这个安全策略就是空的。
我面过的一个candidate在HC（hiring committee）环节被reject，不是因为技术不过关，而是因为他在behavioral interview里说“安全是security team的事情”。HC的反馈是：这种认知在五年前可以接受，现在不行。SRE必须是安全的第一道防线，而不是把安全问题踢给另一个团队。
跨团队协作：SRE不是孤岛
SRE最容易犯的错误是把自己当成一个技术岗位。但SRE的本质是一个桥梁岗位——连接开发和运维，连接业务和技术，连接产品和基础设施。大多数SRE的失败不是因为技术不够强，而是因为跨团队协作能力为零。
入职90天内，你必须建立三个跨团队关系。第一个是和你服务的业务团队的关系：谁是product manager，谁是tech lead，谁是日常需求的对接人。第二个是和你依赖的基础设施团队的关系：如果你们公司有专门的infra team，你必须知道他们的on-call schedule和escalation path。第三个是和你汇报线的关系：你的manager对SRE的理解是什么，他期望你做什么不做什么。
一个真实的场景是某SRE入职两个月，和开发团队关系极差，原因是他在code review里频繁要求重构代码，理由是“可运维性差”。开发团队的反馈是：这个人不懂产品需求，只懂技术理想。三个月后这个SRE被pip（performance improvement plan）了。
问题不在于“可运维性”不重要，而在于这个SRE没有用对方式。他应该做的是和product manager对齐“我们需要什么样的可运维性”，然后把这个需求变成开发团队可以接受的形式，而不是直接说“你这个代码写得不对”。SRE的工作不是证明别人错了，是让系统可靠地运行。如果你的协作方式让系统不可靠了——因为团队不愿意和你合作——那你的SRE就是失败的。
准备清单
入职前30天你需要完成五件事情。第一，找到过去六个月的post-mortem报告，从第一页读到最后一页，不是学习写法，是理解这个公司怎么对待故障。第二，找到公司的SLO定义文档，不是看有没有，是看有没有被实际使用——去问一个简单的问题：过去一个季度有没有因为SLO breach触发过任何行动。第三，找到on-call schedule，理解谁在什么时候被page，为什么被page。第四，找到监控告警的所有权文档或者人，问清楚告警策略是谁写的，为什么这么写。第五，找到一个愿意带你吃饭的老员工，不是技术问题，是问“这家公司有什么坑”。
入职31-60天你需要完成三件事情。第一，参与至少一次on-call rotation的shadow，不是坐在旁边看，是真正接一次page然后处理。第二，找到change failure rate的数据，如果没有人知道这个数据，你找到了就是你的第一个value add。第三，和你服务的业务团队做一次对齐会议，不是技术会议，是问他们“你们最担心什么”。
入职61-90天你需要完成两件事情。第一，做一次自己负责领域的capacity planning，写一个简单的文档，不需要完美，只需要把“流量增长10倍会怎样”这个问题回答了。第二，找到自己的sponsor——不是manager，是那个愿意在关键时刻替你说一句话的senior leader。
在准备清单的最后提一下，PM面试手册里有完整的跨部门协作框架实战复盘可以参考，里面的角色分工和沟通模板对SRE同样适用。
常见错误
第一个常见错误是“技术先行”。BAD版本：新入职SRE花两周时间把所有技术栈研究了一遍，笔记做了五十页，第三周上线第一个变更，出了一堆低级错误。GOOD版本：第一周先找到那个愿意带你吃饭的老员工，问清楚哪些事情重要，哪些事情不重要，哪些坑要避开，然后用20%的时间了解技术栈，80%的时间建立人际关系。技术可以后面补，人际关系入职第一周不建立，后面就难了。
第二个常见错误是“假设自己什么都能改”。BAD版本：新入职SRE看到任何不顺眼的地方就写RFC（request for comment）要求改革，第一季度提了八个RFC，全部被reject，开始觉得公司有问题。GOOD版本：入职前三个月只做一件事——理解为什么事情是这样运转的。不是认同，是理解。理解之后再决定哪些事情值得推动改革，哪些事情不值得你花政治资本。SRE的工作是让系统可靠，不是让你自己爽。
第三个常见错误是“把文档当现实”。BAD版本：新入职SRE按照incident response文档做了一次模拟演练，发现流程完美，觉得这家公司SRE成熟度很高。GOOD版本：找到过去三个月的post-mortem，对比文档和现实。文档里写的流程在实际事故中执行了多少，执行了多少次就说明这个流程有多真实。某公司文档里写的是“incident commander必须在15分钟内assign”，实际过去一年的incident里只有20%做到了。这个差距就是SRE的value add空间。
FAQ
Q1：入职后发现技术栈和面试时说的完全不一样，该怎么办？
这不是一个“怎么办”的问题，是一个“你当初为什么没发现”的问题。面试时你一定问了技术栈的问题，面试官一定给了回答。你需要反思的是：你是怎么理解那个回答的。大多数候选人在面试时听到“用Kubernetes”就直接跳到“会用K8s”，没有追问“我们怎么用K8s”——是self-managed还是EKS/GKE，有没有用GitOps，CI/CD pipeline是什么。入职后发现不一样，90%的情况是你当初问得不够深。
具体做法是：入职第一周不要急着学新东西，先把面试时问的问题重新问一遍，这次问得更深。如果发现确实有重大差异，记录下来，找manager对齐。记住，你的manager知道你问的是废话问题不重要，重要的是你用这个问题来建立“你是一个仔细的人”的印象。
Q2：on-call第一周就被page搞心态，如何调整？
这是每个SRE都会经历的，区别在于有些人调整过来了，有些人没有。调整的关键是把“被page”从情绪问题变成技术问题。具体做法是：被page之后，先不要急着关掉alert，先把alert的触发条件、上下文、之前的处理记录全部看一遍。然后问自己一个问题：如果这个alert再响一次，我能不能在30秒内判断是不是real incident。
如果答案是不能，这就是你的学习方向。某SRE入职第一个月被page了二十次，其中十五次是false positive。他做了一个简单的动作：把每个false positive的触发条件记录下来，找到了告警策略的维护者，一起优化了阈值。三个月后他的false positive率下降了70%。被page不是问题，被page之后什么都不做才是问题。
Q3：SRE的薪资到底有多少？
这是很多人关心但没有人说清楚的问题。以硅谷一线公司为例，SRE的薪资分为三部分。Base salary（基本工资）：根据经验级别，entry level（0-2年经验）在$130K-$160K，mid-level（2-5年经验）在$160K-$200K，senior（5年以上经验）在$200K-$250K。RSU（限制性股票）：四年 vesting，第一年25%，后面三年每个月约2%，entry level在$30K-$60K一年，mid-level在$60K-$120K一年，senior在$120K-$200K一年。Bonus（奖金）：根据公司业绩和个人绩效，通常是base的10%-20%，entry level在$15K-$30K，senior在$25K-$50K。
总包计算：entry level total在$175K-$250K，mid-level在$245K-$350K，senior在$345K-$500K。注意这是2024年硅谷一线公司的范围，二三线公司会低20%-30%。如果你面的公司给的数字显著低于这个范围，要么是你面的级别不对，要么是这家公司对SRE的定位有问题。
准备好系统化备战PM面试了吗？
也可在 Gumroad 获取完整手册。